Génération stratégique de code pour la maîtrise des performances de systèmes temps-réel embarqués. (Strategic generation of code to master the performances of real-time embedded systems)

Analysis Pour répondre à l’objectif no 3, à chaque transformation va éventuellement succéder une analyse évaluant l’impact du raffinement sur les performances du système. Le type AbstractAnalysis modélise une étape d’analyse générique. Celle-ci se décline en Analysis pour une unique analyse associée à une transformation ou en AnalysisSequence pour une succession d’analyses : on distingue les sous-types Conjunction et Disjunction qui indiquent que l’ensemble des analyses doit être validé, ou au contraire qu’une unique analyse de la séquence doit être validée, pour que la transformation soit considérée valide. On connecte l’attribut element d’un objet Transformation à un objet héritant de AbstractAnalysis. Par exemple, après un raffinement de la spécification métier d’une tâche et une réévaluation de son WCET, on réalise une analyse d’ordonnancement pour évaluer l’impact de cette nouvelle estimation. Une étape d’analyse spécifie alors l’identifiant de l’outil de validation que l’on souhaite utiliser (attribut method). L’outil doit être préalablement enregistré dans le processus avec un identifiant unique. Il peut s’agir d’un outil externe existant (e.g. Cheddar, AADLInspector, Bound-T) ou interne au processus (analyse de WCET à partir de modèles). Chaque analyse fournit des résultats normalisés selon le métamodèle illustré par la figure 5.3 dans le but d’assurer une intégration et une compatibilité au sein du processus. FIGURE 5.3 – Méta-modèle de chaîne de raffinement : normalisation des résultats d’analyse L’ensemble des résultats d’une analyse sont modélisés par des objets de type AnalysisResult regroupés dans un objet de type AnalysisArtifact. On distingue deux types de résultat : qualitatif ou quantitatif. Dans le premier cas, il s’agit d’une réponse binaire à un test (le test a t-il réussi ?). Dans le second cas, le résultat indique une marge par rapport à une propriété particulière : par exemple, la marge entre l’échéance d’une tâche et son pire temps de réponse. Dans la première situation, 5.1. PROCESSUS D’ANALYSE ET DE TRANSFORMATION 57 le résultat d’analyse suffit pour déterminer si le raffinement actuel est approprié. Dans la seconde, l’utilisateur va potentiellement décider si le raffinement est approprié en se basant sur les marges affichées. On spécifie alors pour chaque analyse, le mode d’exécution (automatique ou manuel) qui détermine si l’utilisateur doit intervenir dans le processus décisionnel. Afin de retracer chaque analyse, les résultats s’accompagnent d’un objet de type AnalysisSource qui indique notamment les éléments du modèle qui ont été analysés, avec quel outil/méthode (attribut method). Chaque analyse doit influencer le déroulement du processus afin de répondre à l’objectif no 4. Pour cela, après chaque étape AbstractAnalysis, le processus se divise en deux branches. La branche sélectionnée dépend du résultat d’analyse (selon si l’analyse réussie ou échoue). Ces deux branches correspondent aux attributs validOption et invalidOption de l’objet AbstractAnalysis. Ainsi, dans le cas où l’analyse échoue, on modélise un changement de stratégie en reliant l’attribut invalidOption à une nouvelle étape de transformation. Dans le cas où l’analyse réussie, l’objet connecté à l’attribut validOption correspond alors à la prochaine étape du processus. FIGURE 5.4 – Modélisation partielle de deux processus : l’un définit deux raffinements successifs, le second définit deux raffinements alternatifs La modélisation de raffinements successifs ou alternatifs est déterminée par l’enchaînement d’étapes de type Analysis et Transformation. Cela est illustré par la figure 5.4. Celle-ci donne un exemple de deux processus. Celui du haut définit deux raffinements successifs. L’attribut inputModelIdentifier du second raffinement correspond à l’attribut outputModelIdentifier du premier. Cela signifie que le second raffinement s’applique sur le modèle raffiné issu du premier. Le processus du bas défini deux raffinements alternatifs. Après le premier raffinement, une analyse est effectuée. Si l’analyse échoue (branche invalidOption), un raffinement alternatif est réalisé. Dans ce cas, l’identifiant inputModelIdentifier des deux raffinements a la même valeur. Cela signifie que le modèle d’entrée des deux raffinements est le même (le premier modèle raffiné n’est pas pris en compte). Loop En chaînant les étapes Transformation et Analysis on modélise ainsi le choix d’une stratégie parmi un ensemble de stratégies alternatives. Cependant, cette modélisation complexifie considérablement la modélisation du processus lorsque que celui-ci réalise des choix stratégiques sur 58 CHAPITRE 5. CONTRIBUTION des éléments différents de l’architecture (e.g. communication entre tâches, communication entre noeuds, synchronisation). Pour améliorer la lisibilité du modèle, nous définissons le type Loop qui est équivalent à une chaîne d’étapes de raffinements alternatifs. Un objet de type Loop est associé à une liste de stratégies alternatives de raffinement (chacune étant modélisée par une liste de modules) qui sont évaluées les unes après les autres jusqu’à obtenir une stratégie valide. Toutes les stratégies associées à l’objet Loop sont validées par la même analyse associée à cet objet. La branche validOption de cette analyse correspond au cas où l’une des stratégies a été validée. Cet attribut indique la prochaine étape du processus dans ce cas. La branche invalidOption correspond au cas où aucune des stratégies alternatives n’a été validée : cela signifie qu’aucun raffinement n’est valide pour un élément de l’architecture. Cette branche est alors soit associée à un objet de type ErrorState soit à toute autre étape annulant un ensemble de raffinements précédents (en repartant d’un modèle intermédiaire). Serialization La sérialisation est la sauvegarde d’un modèle raffiné en le traduisant en version textuelle. L’ensemble du modèle raffiné est sauvegardé afin d’éventuellement le réutiliser et l’analyser dans un autre processus, notamment pour la certification (objectif no 5). L’étape de Serialization indique alors l’identifiant du modèle à sauvegarder (attribut outputModelIdentifier). L’utilisateur spécifie à quels moments du processus le modèle raffiné doit être sauvegardé. La sérialisation est explicitée par l’utilisateur. Ainsi, une étape Serialization succède à une étape de type Transformation ou Analysis. Generation La génération de code est l’étape finale du processus et consiste à traduire le modèle raffiné en code exécutable (objectif no 6). Le générateur est sélectionné en fonction de la plateforme d’exécution ciblée spécifiée à la configuration. Celui-ci traduit le modèle raffiné en langage cible et n’introduit aucune ressource supplémentaire non modélisée de manière à garantir la cohérence du processus. Chaque générateur agit de façon similaire à un pretty-printer et cela a déjà été expérimenté dans [59]. Dans notre cas, nous fournissons des générateurs de code pour des plates-formes ARINC653, POSIX, OSEK et Ada Ravenscar. Nous avons introduit le méta-modèle qui modélise des processus de raffinement incrémental. En particulier, chaque étape de type Transformation, modélisant un raffinement, est définie à partir d’une liste de modules de transformations afin de réaliser l’adaptation de la transformation en répondant ainsi à la problématique de l’adaptabilité du processus de génération (abordée en section 5.2). Nous nous appuyons pour cela sur la technique existante de superimposition qui est introduite dans la section suivante. 5.1.3 Superimposition Nous avons présenté précédemment le méta-modèle de chaîne de raffinement et en particulier les étapes de Transformation constituées d’un ensemble de modules de transformation afin de répondre à l’objectif no 2. Le principe d’assemblage des modules correspond au mécanisme existant de superimposition [94] que nous présentons ici. Une étape de raffinement/transformation est définie par une liste ordonnée de modules. Un module est une entité logique dans laquelle des règles de transformation sont définies. Afin de rem5.1. PROCESSUS D’ANALYSE ET DE TRANSFORMATION 59 placer une règle d’une étape de raffinement, nous utilisons la technique de superimposition des langages comme ATL : si plusieurs règles ont la même définition (nom et type) au sein de modules différents, seule est chargée la définition du dernier module. Plus formellement, pour une étape de raffinement constituée des modules (M,{M1,M2,M3}) avec M le module principal et M1..M3 les modules superimposés, les règles définies dans M sont remplacées par les règles de même définition dans M1. Les règles définies dans M∪M1 sont remplacées par les règles de même définition dans M2. Cette technique est illustrée par la figure 5.5. L’ensemble des noms de règles est R1, R2, R3, R4. Des règles de même noms sont présentes dans différents modules. La figure donne l’ensemble des règles issu de la superimposition de ces modules. FIGURE 5.5 – Illustration de la superimposition sur trois modules M1, M2, M3 Cela contraint notre approche par la nécessité d’écrire ou de réécrire les règles de transformation en identifiant les parties pouvant évoluer selon le contexte. En effet, afin de bénéficier d’une règle existante que l’on souhaite altérer sans la réécrire en intégralité, il faut la scinder afin de redéfinir certaines parties et en conserver d’autres. La prochaine section fournit une méthode d’utilisation du méta-modèle.